Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added AIO tests + PyLint on PR #6

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Added AIO tests + PyLint on PR #6

wants to merge 9 commits into from

Conversation

wtripp180901
Copy link

Will now run SKC AIO tests on PR to ensure tests behave as intended

@wtripp180901 wtripp180901 changed the title Added AIO tests on PR Added AIO tests + PyLint on PR Jan 14, 2025
@wtripp180901
Copy link
Author

needs someone with admin to add ark runners to this repo

@Alex-Welsh
Copy link
Contributor

needs someone with admin to add ark runners to this repo

@MaxBed4d do you think you could lead this effort?

name: aio (Rocky 9 OVS)
uses: stackhpc/stackhpc-kayobe-config/.github/workflows/stackhpc-all-in-one.yml@parameterise-aio-tests # todo: change after merge
with:
kayobe_image: ghcr.io/stackhpc/stackhpc-kayobe-config:stackhpc-2024.1
Copy link
Contributor

@Alex-Welsh Alex-Welsh Jan 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might require a bit more planning
In SKC, we build the image as a prerequisite job (called here, workflow here)

So that runs every time the workflow is triggered. That's necessary for SKC because the changes to be tested get baked into the image. In this case we just want the latest stable image. We can't just pull the most recently built image because that might've been built from a feature branch, not main.

So we can either:

  1. Rebuild the image from the main branch of SKC every time we run this workflow. (Easy, less efficient)
    OR
  2. Change SKC so when a PR gets merged into main, we give it some "latest" tag, and we reuse that (Harder, more efficient)

I'm leaning towards option 1, since the efficiency gains are minimal and I don't think it's worth the extra dev time. At some point if the scope of this repo grows it might become worth it but we'll deal with that if/when it happens

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants